home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950528-19950726
/
000408_news@columbia.edu_Sat Jul 22 16:36:35 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05323
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sat, 22 Jul 1995 12:36:42 -0400
Received: by apakabar.cc.columbia.edu id AA20987
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 22 Jul 1995 12:36:40 -0400
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit download from CompuServe.. best setup??
Date: 22 Jul 1995 16:36:35 GMT
Organization: Columbia University
Lines: 65
Message-Id: <3ur9ej$kfp@apakabar.cc.columbia.edu>
References: <3uidtu$r5c@hpber004.swiss.hp.com> <DC095G.Dp3@omen.com> <3ulp8c$ep5@apakabar.cc.columbia.edu> <DC4Cr1.BB8@omen.com>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <DC4Cr1.BB8@omen.com>, Chuck Forsberg WA7KGX <caf@omen.com> wrote:
>
> Developers such as Datastorm and CompuServe tend to make use of
> royalty-free code when implementing protocols. The most recent
> royalty-free Kermit code released with the blessing of Columbia
> University is "The Source" SuperKermit code published in the middle
> 1980s. As Frank himself has commented, this version of Kermit was not
> robust. Its poor performance prompted GTE Telenet to commission the
> creation of ZMODEM in 1985/1986. The rest is history.
>
I think you and I would both like it better if these companies, when
marketing our respective protocols, would work out arrangements with us to
license the most up-to-date versions. I have no doubt that ZMODEM-90 is
superior in all ways to to 1986 ZMODEM, just as modern Kermit software is
superior to the ten-year old version of Kermit from "The Source". It is
appalling that companies like Datastorm and CompuServe do not elect to
support the people who did all the R&D that went into key portions of
their products and services, but rather, take whatever they can get for
free no matter how junky it is. Their customers suffer for it, Chuck and
I get the bad rap, and, in most cases, the tech-support fingers at these
companies point back at us: "ZMODEM problem? Chuck's fault, blame him.
Kermit problem? Frank's fault, blame him." Yet, with almost unfailing
certainty, every such problem has already been addressed and fixed over
the ensuing years by the original developers, a fact which could not
concern these companies in the least. "We have your money, we don't care!"
> CompuServe claim they have not widely deployed ZMODEM because it
> consumes too many resources. I suspect CompuServe have made the
> same measurements of system resources consumed by sz and Ckermit
> and concluded that Ckermit is far more resource intensive than sz.
>
Which is, of course, a non-issue. If CompuServe were interested in a
decent ZMODEM or Kermit implementation, they would talk to Chuck or me
about it ( respectively :-) and we would work with them to ensure that
they had a product that would meet or exceed their requirements. In fact,
what they are interested in is being able to simply put the word "ZMODEM"
or "Kermit" on their literature for lip service to "de facto standards"
to attract customers. They don't want to do the right thing, they want
to do the least amount of work and spend the least amount of money
required to get YOUR money.
> CompuServe has enhanced their B protocol with 32 bit CRC and streaming
> data transfer to provide excellent throughput downloading the types of
> files users download from CompuServe.
>
Well sure they do. But having one's own proprietary protocols turns out
to bite one back in the end. How many telnet clients do we know of that
support B+?
> ... CompuServe may not wish to make this change, which would increase
> system load and break some programs written to the 1985 Kermit spec.
>
The spec hasn't changed. Today's Kermit software is written to the 1987
(not 1985) spec, as given in the Kermit book (with extensions, but not
with changes, and the extensions are in other areas entirely, such as
character sets). The Source's implementation, which was a pioneering
effort and, I'll even say, a landmark in the history of our little corner
of the world, had, shall we say, implementation problems. That it should
have found its way into so much junky commercial and shareware software is
a strong argument against ever again turning such software loose without
protection. When you're "nice" in this business, everybody takes advantage.
So what is the lesson here?
- Frank